【レポート】最新の DWH およびデータレイク動向について(AWS-36) #AWSSummit

【レポート】最新の DWH およびデータレイク動向について(AWS-36) #AWSSummit

Clock Icon2022.05.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさんこんにちは、杉金です。

今回は 2022 年 5 月 25 - 26 日の 2 日間開催された AWS Summit Onlineのセッションレポートをしていきます。セッションのサマリーを理解し、興味があるセッションをチェックすることにご活用ください。また、セッションのアーカイブも公開されておりますので、詳細が気になった方は是非そちらをチェックして下さい。

セッション概要

生成されるデータ量は増え続け、データ分析のニーズも多様化が進んでいます。従来の方法でこれらの要件を全て満たそうとすると、システムやその管理は複雑化しがちですが、AWS の分析サービスではモダンデータ戦略というアプローチでこの課題に対する様々な解決策を提供しています。本セッションでは、Amazon Redshift を中心に、データレイクと連携した様々な目的別分析サービスを簡単に組み合わせて、それぞれの分析ニーズに最適化された方法で、誰でも簡単に分析に集中するための方法をご紹介します。

スピーカー

AWS 技術統括本部 ソリューションアーキテクト 鈴木 浩之 氏

セッションレベル

Level 300: 中級者向け

アジェンダ

  • モダンデータ戦略と目的別分析サービス
  • 進化したデータウェアハウス Amazon Redshift
  • まとめ

レポート

モダンデータ戦略と目的別分析サービス

データ量の増加傾向

  • 20年前の1年間に生成されるデータ量より、現在の1時間あたりに生成されるデータ量の方が多い
    • データが増えることで様々なインサイトを獲得して大きなチャンスを得られるが、多くのデータを扱うことは多くのチャレンジを伴う

データ分析に関する様々な課題

  • データのサイロ化(システムが分断、それぞれが統合されていない状態)
    • 分析したいデータがすぐに検索できない
    • 経路が複雑で連携が困難
  • 分析ニーズの多様化
    • 役割やスキルセットが異なる様々な分析者が増える
    • 使いたいツールや方法が違うため、ニーズに柔軟に応えるのが難しい
  • 拡張性とコスト
    • データが増えてニーズも多様化、複雑なシステムでは拡張が困難
    • 無理に拡張すると結果的にTCOという観点でコストに跳ね返ってくる
  • AWSではこのような課題に対してモダンデータ戦略というアプローチを推奨している

モダンデータ戦略

  • スケーラブルなデータレイクを中核にもち、ニーズに最適化された分析サービスを使い分ける方法
  • 一つの汎用的なツールを使って全てのことを満足させようとすると、突き詰めたときに限界が訪れる
  • 重要なのは簡単にそれらが使えること、各サービスが統合的にアクセスできてガバナンスを効かせることができること
  • 機械学習などの高度な機能をユーザーが意識せずに使えるビルトインという要素も大きなポイント

様々なニーズに最適化された分析サービス例

  • エグゼクティブ、ビジネス部門の場合
    • 可視化されたダッシュボードやGUIを使った分析をしたい
      • Amazon QuickSight(BI・ダッシュボード)
  • データアナリストの場合
    • BIだけでなくSQLを使って、大規模なデータに対してクエリを投げて集計したい
      • Amazon Athena(インタラクティブクエリ)
      • Amazon Redshift(データウェアハウス)
  • データサイエンティストの場合
    • 機械学習を使いたい
      • Amazon SageMaker(機械学習)
  • データエンジニアの場合
    • HadoopやSparkのようなビッグデータのフレームワークを活用したい
      • Amazon EMR(ビッグデータフレームワーク)
  • ユーザー層によって使いたいインターフェースやスキルセットが異なる
    • AWSではそれぞれに最適化された様々なサービスを提供している
    • サービスが増えるとセットアップや管理、コストが気になる
      • サーバーレスで解決

サーバーレスとは

  • サーバーの存在を意識せずに機能を簡単に使える仕組み
    • ワークロードを回す場合はワークロードに応じたスケーリングが必要
      • サーバーレスの場合はスケーリングは全て自動化
    • 使っていない時間はリソースが自動的に解放
      • 使わない時間にコストがかからずコスト最適化が図れる
    • 高可用性やメンテナンスなどの運用に必要なものもビルトインされている
  • サーバーレスがもたらす効果
    • 複雑なセットアップや設計が不要
    • 小規模なユースケースから大規模にスケールするところまで自動的に利用が可能
    • 分析者が少人数、あるいはインフラエンジニアが十分にいないような小規模なケースでも簡単に構築して運用が可能
    • 使った分だけの課金
    • 最終的に本来やりたい分析に集中できる

サーバーレスの選択肢の拡大

  • データ分析の四要素(収集→保存→変換→分析)
    • AWSではこれらの要素に対してサーバーレスで実現するサービスを提供
      • 収集
        • Amazon Kinesis Data Streams On-Demand[Updated]:リアルタイムストリーム
        • AWS Glue(Crawler / Connector):汎用データ連携
        • Amazon MSK Serverless[New]:リアルタイムストリーム(Apache Kafka)
        • Amazon AppFlow:SaaS連携
      • 保存
        • Amazon S3:データレイク
        • AWS Lake Formation:ガバナンス
        • AWS Glue Data Catalog:データカタログ
      • 変換
        • AWS Glue,AWS Glue DataBrew:ETL・プレパレーション
        • Amazon EMR Serverless[New]:並列分散処理
        • AWS Step Functions:データフロー制御
      • 分析
        • Amazon Athena:インタラクティブクエリ
        • Amazon QuickSight:BIダッシュボード
        • Amazon Redshift Serverless[New]:データウェアハウス
        • Amazon EMR Serverless[New]:並列分散処理
  • 新たに追加された四つのサービスについて紹介
    • Amazon Kinesis Data Streams On-Demand
      • ストリーミングデータを扱うサービスで、新たにオンデマンドモードが追加
        • 従来のモードではワークロードに応じたシャード数のチューニングが必要
        • オンデマンドモードではワークロードに応じて自動的にスケールされる
    • Amazon MSK Serverless
      • オープンソースのApache Kafkaのマネージドサービスで、新たにサーバーレスのオプションが追加
        • KafkaConnectのようなKafkaのエコシステムも利用可能
    • Amazon EMR Serverless
      • HadoopやSparkのようなビッグデータのフレームワークを使うサービスで、新たにサーバレスのオプションが追加
        • 従来ではクラスターを立ち上げてジョブを実行して完了したらターミネートするパイプラインを組むケースが多いが、サーバーレスの場合はフレームワークを指定してジョブをサブミット(送信)するとジョブが実行されて終わったら自動的にリソースが解放される。パイプラインを簡素化できる
    • Amazon Redshift Serverless
      • 大規模なデータに対してクエリを実行できるデータウェアハウスのサービスで、新たにサーバレスのオプションが追加

ユースケース別サーバーレスで実現するデータ分析基盤例

  • 一人もしくは少人数で大規模なデータを分析したい
    • Amazon S3をデータレイクに使用
    • Amazon Redshift Serverlessを使うと簡単にサービスの環境を立ち上げてすぐに分析が実行可能となる
  • ある程度ユーザーやメンバーが増えてきて、使いたいサービスやインタフェースが変わってくる
    • EMRやQuickSightのような、サーバーレスでも提供しているサービスをうまく組み合わせることで柔軟にかつ迅速にニーズに応えることが可能
    • データをS3のデータレイク上に格納して、AWS Lake Formationサービスを活用すると様々なサービスにまたがった形で統合的にアクセス権限やガバナンスを効かせる仕組み作りも可能
  • データ自体はデータベースやSaaSなど外部にあるケースでデータレイクに取り組む方法としてもサーバーレスのデータ収集の選択肢がある
  • さらに大規模になってきたお客様のケースだと、ドメインごとにすでにデータレイクが分かれていたり企業間でデータをやりとりしたいケース
    • 近年ではデータメッシュという考え方が提唱されている
      • AWS Lake Formationではアカウントをまたいでカタログやガバナンスを共通的に管理する仕組みがあり、この仕組みを利用してデータメッシュを作ることも可能
        • JPMorgan Chase社ではAWS上でデータメッシュを実現している

進化したデータウェアハウス Amazon Redshift

大規模データクエリのための目的別分析サービス Amazon Redshift

  • Redshiftでは3つの要素でアップデートを進めている
    • 誰でも簡単に分析ができる
    • すべてのデータを分析する
    • 大規模環境でのパフォーマンス
  • 全世界で毎日何万人ものユーザーがRedshiftを使ってエクサバイト級のデータ処理を実行
    • 多くのユーザーの声を元にRedshiftは日々アップデートしている
  • 誰でも簡単に分析ができる
    • インフラを気にせず大規模な分析をしたい
      • Amazon Redshift Serverless
        • インフラストラクチャの管理が不要
        • インサイトを数秒で取得
        • Amazon Redshift Serverlessを実際に利用するにはサーバーレスのエンドポイントを有効化にする
        • エンドポイントに対してクエリを投げるだけで最適な結果を返してくれる
        • 従来のクラスターで構成されたProvisioned型のサービス機能を踏襲している
        • 従来のモデルでもスケールの設定等は簡単にできるが、さらにその抽象度を高めて事前の設計やサーバーに関して意識不要で大規模な分析が可能
        • 費用に関しては使った分だけ
        • 実際にワークロードが実行されるとRPUというコンピュートが割り当てられる。そのコンピュートの実行時間
        • データをためるストレージ、Redshift managed storageというS3をバックボーンとしたストレージ領域があり、そこに対しての蓄積量にお応じた従量課金
        • クエリサービス使い分け
          • Amazon Athnea:データレイクに対して簡単にクエリを投げる、たまに使うようなケースにフィット
          • Amazon Redshift Provisioned:より複雑な規模、大規模なワークロード向け
          • Amazon Redshift Serverless:両者の中間(いいとこ取り)
            • AthenaやRedshift Spectrumはクエリスキャン量による課金だが、Redshift Serverlessはワークロードの実行時間。ワークロードが早く終われば課金が少ない
    • 自分に合った分析ツール・方法をサクッと使いたい
      • セットアップ不要のRedshift用のWeb型クエリエディタ
        • シングルサインオンに対応
        • データの直接インポート(CSV)/エクスポート(CSV/JSON)が可能
        • クエリエディタの追加料金はなし
        • チーム共有可能(クエリ、チャート、Notebook)
        • クエリ資産は変更履歴を自動管理
      • 最適化された専用サービスと連携
        • QuickSightからデータソースとしてRedhisftを選択でき、Redshiftのデータをリッチに可視化
        • AWS Glue DataBrewでデータを整形してRedshiftに連携
        • その他(Grafana, SageMaker, 3rd Party)
    • 高度な分析を誰でも簡単にできるようにしたい
      • 使い慣れたSQLで機械学習
        • Redshiftに機械学習の機能があり、SQLだけで機械学習のモデルの開発や学習予測が可能
        • さまざまなアルゴリズムに対応
        • Auto ML機能
        • 独自モデルをインポートして利用も可能
  • すべてのデータを分析する
    • 様々なデータをラクに取り込みたい
      • データベースの場合
        • AWS DMS(DBレプリケーション)
        • AWS Glue(汎用ETL)
      • SaaSの場合
        • Amazon AppFlow(SaaSデータ連携)
      • ストリームデータ(App/IoT)の場合
        • Amazon Kinesis Data Firehose(ストリーム連携)
      • リアルタイムデータ連携
        • Kinesisデータストリームのストリーミング取り込み
          • Kinesis Data Streamsの複数のストリームに対してマテリアライズドビューという形で直接データの取り込みが可能
    • 外部データに直接アクセスしたい
      • リレーショナルデータベースの場合
        • フェデレーテッドクエリに対応
        • 負荷が気になる場合はリードレプリカを介する
      • データレイクの場合
        • Spectrum/DataLakeで直接クエリを投げる
      • NoSQLデータベースの場合
        • 仮想テーブル空間をもつAWS Glue Elastic Views
          • マテリアライズドビューを生成して異なるデータソースとのデータ連携を可能にする
      • 組織や企業を跨いだデータ共有
        • Amazon Redshift managed storage
          • データの移動がなく権限設定だけで相互にデータの共有が可能
          • ServerLess型とProvisioned型双方での連携も可能
    • そもそもデータを持っていない
      • 3rdパーティーデータをマーケットプレイスから
        • Amazon Data Exchange for Amazon Redshift
        • 各会社が提供するデータをサブスクリプションという形で利用可能
        • 決済や課金の制御もマーケットプレイス上で実現
        • データ共有に対応したデータはデータの移動や事前コピー不要で利用可能
  • 大規模環境でのパフォーマンス
    • 自動化されたパフォーマンスチューニング
      • 物理データ配置やその最適化を自動化
      • 機械学習アルゴリズムを用いてクエリを実行するために必要なリソースを動的に管理(WLM)
    • 自動マテリアライズドビュー
      • 頻繁に実行されるクエリの自動的なパフォーマンス向上
      • クエリリライトと自動リフレッシュ機能を合わせ、ユーザーは意識せずに最も高速なクエリ結果を得られる

その他 分析に役立つ様々な機能アップデート

  • 空間データ(spatial data)
    • GEOMETRY型とGEOGRAPHY型の二つに対応
    • 緯度経度を使った大規模なデータ分析が可能
  • SUPER型:半構造化データ
    • JSONなどの半構造化データを事前のパース処理不要で取り込み、分析が可能
    • PartiQLによりスキーマレスのネストされたデータへも効率的アクセス可能
  • PIVOT / UNPIVOT
    • 簡単なSQL操作でテーブルのピボット操作が可能
  • スカラーLambda UDF
    • AWS Labmdaで定義されたカスタム関数をSQLクエリの一部として使用可能
    • Redshiftが持っていない機能を自身で拡張する

まとめ

  • モダンデータ戦略と様々なニーズに最適化された目的別分析サービスを簡単に組み合わせて柔軟に拡張
  • Analyticsサービスへのサーバーレスの選択肢の拡大。運用管理から解放され、分析に集中できる。
  • Amazon Redshiftで誰でも簡単に様々なデータを大規模にスケールして分析できる

感想

どのようなケースで何のサービスを使うかが分かりやすく、それでいて網羅的だったので理解しやすかったです。セッションを受ける前まではアップデートした機能の中で使いどころが分かってない機能があったのですが、ユースケースを交えて紹介して下さったのでこのセッションを通じて理解できました。今後役立ちそうな情報ばかりでしたのでセッション資料は家宝にします!

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.